COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	THE COMMON BUSINESS COMMUNICATION LANGUAGE
C00012 ENDMK
C⊗;
THE COMMON BUSINESS COMMUNICATION LANGUAGE


	Here are some ideas about the value of a %2common business
communication language%2 (CBCL for short) and what its characteristics
might be.

	The need for such a language was suggested to me by an
article by Paul Baran that appeared in %2Public Interest%1 in 1965.
In this article, Baran envisaged the world of the future in which
companies would be well equipped with on-line computer systems.
He envisaged a time when the inventory control computer of company
A would cause to appear on the screen of a clerk in the purchasing
department a statement that 1000 gross of such-and-such pencils
were needed and that they should be purchased from company B.
The clerk would turn to her typewriter and type out a purchase
order.  At company B another clerk would receive the purchase
order and turn to her terminal and tell the system to arrange to
ship the pencils.  Curiously, the possibility of eliminating both
clerks by having the computers speak directly to each other was
not mentioned in the article.  Perhaps the author felt that he
was already straining the credulity of his audience.

	Let us now suppose that we wish to eliminate the clerks
by having the computers speak directly to each other.  %1What
are the requirements?%1

	First, computers do communicate directly now.  Already
in the 1950s, the Social Security Administration announced
a tape format for IBM seven channel magnetic tape on which
it was prepared to receive reports of earnings and payroll
deductions.  Note the limitations: (i) magnetic tapes are
mailed rather than direct electronic communication - admittedly
entirely appropriate in this case.  (ii) A single fixed kind
of message with a fixed set of parameters for each report.
(iii) A "monopolistic" situation where one agency can dictate
the format.
Besides this early case, there are many other cases in which
information is exchanged electronically between computer
systems belonging to different organizations.  often this
is by specific treaty betwen the two organizations and
sometimes a group that will be communicating have collectively
agreed on formats.  Another example is the U.S. Navy's
system for exchanging information among ships about what their
radars and other sensors can see so that each ship can
have the full radar picture acquired by the whole fleet.
In connection with the extension of the system to NATO, it
was completely redesigned, and on a designated day, all
users switched to the new system.

	Our goal is more ambitious in the following respects:

	1. A common language is to be adopted that can express
business communications.  For example, requests for price
quotations, offers to buy and sell, queries about delivery
times and places, inquiries about the status of delayed
orders, references to standard commercial legal agreements.

	2. Any company should be able to communicate with
any other without pre-arrangement over ordinary dial-up
telephone connections.  Of course, this requires authentication
procedures and verification of authorization procedures,
but let us not be unduly distracted by the security aspects
of computing lest we end up with a secure method of communication
and nothing to say.

	3. The system should be open ended so that as programs
improve, programs that can at first only order by stock numbers
can later be programmed to inquire about specifications and
prices and decide on the best deal.  This requires that each
message be translatable into a human-comprehensible form and
that each computer have a way of referring messages it is not
yet programmed to understand to humans.  When a new type of
message is to displace an old one, the programs should be
programmed to send both and continue sending both until the
receivers all are capable of understanding the new form.  In
that way, the crises of cutover days as in the naval example
could be eliminated.

	We are not now interested in the low-level aspects of
the message formats, i.e. what kinds of bit streams and what
kinds of modems, except to remark that the system should
avoid traps in these areas, and the users should be able to change
their systems asynchronously.

	We do not have a final proposal but here are some
ideas.

	1. The messages are lists of items punctuated by
parentheses.  The lead item of each list identifies
the type of message and is used to determine how to
interpret the rest.  The items may be either sublists
or atoms.  If an item is a sublist, its first element
tells how to interpret it.  Atoms are binary numbers of
say 32 bits.  A dictionary tells what each means.  Besides
this, other forms of data may be included provided they
are demarcated by appropriate punctuation and provided
they are pointed at from lists that tell how they are
to be interpreted.

	2. Here are some examples:

	a. (REQUEST-QUOTE (YOUR-STOCK-NUMBER A7305) (UNITS 100))

	b. (REQUEST-QUOTE (PENCILS #2) (GROSS 100))

	c. (REQUEST-QUOTE (ADJECTIVE (PENCILS #2) YELLOW) (GROSS 100))

	d. (WE-QUOTE (OUR-STOCK-NUMBER A7305) (QUANTITY 100)
(DELIVERY-DATE 3-10-77) (PRICE $1.00))

	e. (PLEASE-SAY (IOTA (X) (AND (RED X) 

It appears that some items may require a variable number of
modifiers.

	As a toy example, imagine writing conventions that would
permit any Monopoly-like game to be played by independently
written programs.  Suppose that the moves are communicated to
a referee who receives requests to roll the dice and returns
information about what squares the pieces landed on and what
"chance" cards were drawn.  The programs would communicate offers
to buy and sell directly to each other and to the "banker".